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Survey of Proposed Use Cases for the IPv6é Flow Label 


Abstract 


The IPv6 protocol includes a flow label in every packet header, but 
this field is not used in practice. This paper describes the flow 
label standard and discusses the implementation issues that it 
raises. It then describes various published proposals for using the 
flow label and shows that most of them are inconsistent with the 
standard. Methods to address this problem are briefly reviewed. We 
also question whether the standard should be revised. 
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1. Introduction 

IPv6 is being introduced to overcome the address shortage of the 

current IPv4 protocol, but it also offers a new feature, i.e., the 

Flow Label field in the IPv6 packet header. The flow label is not 

encrypted by IPsec and is present in all fragments. However, it is 

used very little in practice, for reasons discussed below and in 

[Amante11]. After a short introduction, this document summarizes the 

current specification of the IPv6 flow label and some open issues 

about its use in Section 2. Section 3 describes and analyzes various 

proposals that have been made for its use. Finally, Section 4 

discusses the implications and attempts to draw conclusions. 

The Flow Label field occupies bits 12 through 31 of the IPv6 packet 

header. It provides a potential way to mark a packet, identify a 

flow, and look up the corresponding flow state. This field is always 


present in an IPv6 header, so a phrase such as "a packet with no flow 
label" refers to a packet whose Flow Label field contains 20 zero 
bits, i.e., a flow label whose value is zero. 


1.1. A Brief History of the Flow Label 
The original proposal for a flow label has been attributed to Dave 


Clark [Deering93], who proposed that it should contain a pseudo- 
random value. A Flow Label field was included in the packet header 
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during the preliminary design of IPv6, which followed an intense 
period of debate about several competing proposals. The final choice 
was made in 1994 [RFC1752]. In particular, the IETF rejected a 
proposal known as the Common Architecture for Next Generation 
Internet Protocol (CATNIP) [RFC1707], which included so-called ’cache 
handles’ to identify the next hop in high-performance routers. Thus, 
CATNIP introduced the notion of a header field that would be shared 
by all packets belonging to a flow, to control packet forwarding on a 
hop-by-hop basis. We recognize this today as a precursor of the MPLS 
label [RFC3031]. 


The IETF decided instead to develop a proposal known as the Simple 
Internet Protocol plus (SIPP) [RFC1710] into IP version 6. SIPP 
included "labeling of packets belonging to particular traffic ’flows’ 
for which the sender requests special handling, such as non-default 
quality of service or ’real-time’ service" [RFC1710]. In 1994, this 
used a 28-bit Flow Label field. In 1995, it was down to 24 bits 
[RFC1883], and it was finally reduced to 20 bits [RFC2460] to 
accommodate the IPv6é Traffic Class, which is fully compatible with 
the IPv4 Type of Service byte. 


There was considerable debate in the IETF about the very purpose of 
the flow label. Was it to be a handle for fast switching, as in 
CATNIP, or was it to be meaningful to applications and used to 
specify quality of service? Must it be set by the sending host, or 
could it be set by routers? Could it be modified en route, or must 
it be delivered with no change? 


Because of these uncertainties, and more urgent work, the flow label 
was consistently ignored by implementors, and today is set to zero in 
almost every IPv6 packet. In fact, [RFC2460] defined it as 
"experimental and subject to change". There was considerable 
preliminary work, such as [Metzler00], [Conta0Ola], [Conta0lb], and 
[Hagino01]. The ensuing proposed standard "IPv6 Flow Label 
Specification" (RFC 3697) [RFC3697] intended to clarify this 
situation by providing precise boundary conditions for use of the 
flow label. However, this has not proved successful in promoting use 
of the flow label in practice, as a result of which 20 bits are 
unused in every IPv6 packet header. 


1.2. The Flow Label and Quality of Service 


Developments in high-speed switch design, and the success of MPLS, 
have largely obviated consideration of the flow label for high-speed 
switching. Thus, although various use cases for the flow label have 
been proposed, most of them assume that it should be used principally 
to support the provision of quality of service (QoS). For many 
years, it has been recognized that real-time Internet traffic 
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requires a different QoS from general data traffic, and this remains 
true in the era of network neutrality. Thus, an alternative to 
uniform best-effort service is needed, requiring packets to be 
classified as belonging to a particular class of service or flow. 
Currently, this leads to a layer violation problem, since a 5-tuple 
is often used to classify each packet. The 5-tuple includes source 
and destination addresses, port numbers, and the transport protocol 
type, so when we want to forward or process packets, we need to 
extract information from the layer above IP. This may be impossible 
when packets are encrypted such that port numbers are hidden, or when 
packets are fragmented, so the layer violation is not an academic 
concern. The flow label, being exempt from IPsec encryption and 
being replicated in packet fragments, avoids this difficulty. It has 
therefore attracted attention from the designers of new approaches to 
Qos. 


2. Flow Label Definition and Issues 
2.1. Flow Label Properties 


RFC 3697 [RFC3697] standardizes properties of the flow label, 
including the following: 


o If the packets are not part of any flow, the flow label value is 
zero. 


o The 3-tuple {source address, destination address, flow label} 
uniquely identifies which packets belong to which particular flow. 


o Packets can receive flow-specific treatment if the node has been 
set up with flow-specific state. 


o The flow label set by the source node must be delivered to the 
destination node; i.e., it is an end-to-end label. 


o The same pair of source and destination addresses must not use the 
same flow label value again within a timeout of at least 
120 seconds. 


One effect of the second of these rules is to avoid the layer 
violation problem mentioned in Section 1. By using the 3-tuple, we 
only use the IP layer to classify packets, without needing any 
transport-layer information. This may reduce the lookup time if 
flow-based treatment is required and will work even with IPsec 
encryption and fragmentation. Therefore, for traffic needing other 
than best-effort service, such as real-time applications, the flow 
label can be set to different values to represent different flows, 
and each node forwarding or receiving the packets may provide 
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different flow-specific treatments by looking at the flow label 
value. This is more fine-grained than differentiated services 
(Diffserv) [Carpenter02] [RFC2474] but need not be less efficient. 


2.2. Dependency Prohibition 


An additional important rule in the standard [RFC3697] effectively 
forbids any encoding of meaning in the bits of the flow label. To be 
exact, the standard states that "IPv6é nodes MUST NOT assume any 
mathematical or other properties of the flow label values assigned by 
source nodes". This rule is aimed at the case where a packet froma 
source using a particular encoding scheme for the flow label reaches 
a node that is using a different scheme. If, by chance, the bit 
pattern in the flow label is meaningful in both schemes, the receiver 
would misinterpret the flow label. Therefore, in the absence of 
other information, the receiver must not assume anything about the 
meaning of the value of the flow label. 


The standard [RFC3697] also states that "Router performance SHOULD 
NOT be dependent on the distribution of the flow label values. 
Especially, the flow label bits alone make poor material for a hash 
key". The problem this rule is intended to avoid is that if a source 
uses one method of choosing flow labels (e.g., counting up from 1), 
any router that assumes another method (e.g., pseudo-randomness) may 
not perform as intended. 


Note that there is no easy escape from the combination of these two 
prohibitions, which we will call the dependency prohibition. Unlike 
Diffserv code points, flow labels are not locally significant within 
a single administrative domain; they must be preserved end-to-end. 
In general, a router cannot know whether a particular packet 
originated in a host supporting a specific usage of the flow label. 
Therefore, any method that breaks one or both of these rules will 
only work if there is some way for a router to determine which 
sources use the same scheme as itself. 


The interpretation of the dependency rule can be subtle and is not 
spelled out in [RFC3697]. A node must not assume properties of the 
flow label -- but it may know them by construction or by signaling. 
The bits of the flow label alone are poor material for a hash key -- 
but they may be combined with bits from other sources, to provide 
uniformly distributed hash outputs. 


2.3. Other Issues 
[RFC3697] does not discuss how to use the flow label most 


effectively. This remains the major open issue, but some authors 
propose that the label should be used with reserved bandwidth to 
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3. 


achieve customized QoS provision. Coupled with admission control at 
the edge router, this could limit congestion. However, as we will 
see below, this is not the only proposed use. 


We now introduce some other open issues. 


o Unknown flow labels: [RFC1809] proposed that when a router 
receives a datagram with an unknown flow label, it should treat it 
as zero. However, the standard [RFC3697] is silent on this issue. 
Indeed, some methods of flow state establishment might choose to 
use an unknown label as the trigger for creating flow state. 


o Deleting old flow labels: When a flow finishes, how does the 
router know the flow label has expired? Should this be based on a 
timeout, on observation of the transport layer, or on explicit 
Signaling? [RFC3697] defines a timeout (120 seconds) that 
effectively imposes a maximum lifetime on flow label state ina 
router. This implies that flow labeling is inappropriate for very 
intermittent flows, unless there is some mechanism to refresh 
router state. In contrast, [Banerjee02] suggested that a router 
should send an ICMP message to the source prior to deleting a 
particular label. The source node may then send a KEEPALIVE 
message to the router; if it does not, the router will release 
that label. 


o Choosing when to set the flow label: For what kinds of 
applications should we set up non-zero flow labels? [RFC1809] 
suggested not setting it for short flows containing few bytes but 
using it for long TCP connections and some real-time applications. 


o Can we modify the flow label? [RFC3697] states that the flow 
label must be delivered unchanged. There are several advantages 
of immutable flow labels, apart from respecting the standard: the 
rule is easy to understand, does not require extra processing in 
routers or a signaling protocol, and allows for very simple host 
implementations. Also, it is straightforward for hosts and 
routers to simply ignore the flow label. However, this rule does 
appear to exclude any MPLS-like or CATNIP-like use for optimized 
packet switching. Some of the proposed mechanisms described below 
contradict this by suggesting that switches should change the flow 
label for routing purposes. 


Documented Proposals for the Flow Label 


In the following, we do not intend to recommend or criticize various 
proposals. This section shows the variety of proposals that have 
been published, and whether they are compatible with the existing 
standard. These proposals almost all assume that the flow label’s 
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main purpose is to support QoS, and their flow label mechanisms are 
entangled with QoS mechanisms. We describe the proposals in five 
broad, and somewhat overlapping, categories, i.e., 


1. using pseudo-random flow label values for various purposes (for 
example, to improve routing performance when retrieving cached 
routing state); 


2. defining specific QoS requirements as parameters embedded in the 
flow label field; 


3. using the flow label to control packet switching; 


4. using the flow label specifically to extend the existing 
differentiated services QoS architecture; 


5. other uses. 


Among the proposals described in the following five sections, various 
methods are proposed to set up the flow label value. It should be 
noted that some of these proposals embody novel and perhaps 
controversial approaches to QoS provision, and these cannot readily 
be separated from their use of the flow label. We give a reasonable 
amount of technical detail for some of the proposals, to show the 
extent to which they propose detailed semantics for the flow label 
value. 


3.1. Specify the Flow Label as a Pseudo-Random Value 
3.1.1. End-to-End QoS Provisioning 


As our first example, [Lin06] specifies a 17-bit pseudo-random value. 
The figure below shows the proposed flow label structure. 


o The Label Flag (LF) bit: 1 means this type of flow label is 
present. We note that this encoding is incompatible with the 
dependency prohibition in [RFC3697], since a source that does not 
use this method may also set the LF bit. 


o The Label Type (LT): 2 bits; describes the type of packet. 

o The Label Number (LN): randomly generated by the source node. 
[Lin06] also describes a signaling process between source, routing, 
and destination nodes based on this label structure and on the IPv6 
Traffic Class byte, in order to reserve and release router resources 


for a given flow within a given class of traffic. The pseudo-random 
LN value is used to uniquely identify a given flow. 
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Flow Label Specification (figure simplified from [Lin06]) 


4+--+----4----------------------------- + 
ies (ee | 17 bits | 
4+--+----4----------------------------- + 
|IF| LT | LN | 
4+--+----4----------------------------- + 


LF 0 Disable 
1 Enable 
LT 00 Flow label requested by source 
01 Flow label returned by destination 
10 Flow label for data delivery 
11 Flow label terminates connection 
LN Random number created by source 


3.1.2. Load-Balancing 


There have been numerous informal discussions of using pseudo-random 
flow labels to allow load-balancing or at least load-sharing. This 
would be achieved by including the flow label value among the fields 
in each packet header used as input to a modulo(N) hash used to 
select among N alternative paths. However, concerns about the 
interpretation of the dependency prohibition have generally prevented 
such proposals from being written up until recently [Carpenterl11]. 


3.1.3. Security Nonce 


Another proposal for a pseudo-random flow label value is [Blake09]. 
This states that off-path spoofing attacks have become a big issue 
for TCP and other transport-layer applications, and proposes that in 
IPv6 we should set a random value in the flow label to make the 
packet header more complex and less easy for the attacker to guess. 
The two ends of the session will agree on flow label values during 
the SYN/ACK exchange, but off-path attackers will be unlikely to 
guess the agreed value. Naturally, on-path attackers who can observe 
the flow labels in use can trivially defeat this protection. This 
proposal does not involve using the flow label value to retrieve 
routing state. 


3.2. Specify QoS Parameters in the Flow Label 


[Prakash04] proposes to utilize the flow label to indicate required 
QoS parameters in detail. It uses the first few bits of the Flow 
Label field as codes to support different approaches, as summarized 
in the following table. Again, this is incompatible with the 
dependency prohibition in [RFC3697], since a source that does not use 
this method may also set the first two bits to non-zero. 
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Classification for various approaches (from [Prakash04]) 


Bit Pattern Approach 


00 No QoS requirement (Default QoS value) 

01 Pseudo-Random value used for the value of Flow-Label 
10 Support for Direct Parametric Representation 

1100 Support for the DiffServ Model 

1101 Reserved for future use 

HEL Reserved for future use 


This method allows a pseudo-random option but also adds options for a 
direct QoS request and for Diffserv. In the direct QoS parameters 
approach, 18 bits are used to encode requirements for one-way delay, 
IP delay variation, bandwidth, and one-way packet loss. The proposal 
appears to assume that the Resource Reservation Protocol (RSVP) 
[RFC2205] mechanisms are used to actually implement these QoS 
parameters. 


This proposal allows the use of the flow label for various important 
QoS models, so the end user and service provider can choose the most 
suitable model for their situation; [Prakash04] claims that "The 
proposed approach results in a simple, scalable, modular and generic 
implementation to provide for QoS using the IPv6é flow label field". 


Similarly, [Lee04] defines the Flow Label field in five parts, with 
the first 3 bits used as an approach type. The authors define two 
approaches: a "random" scheme and a "hybrid" scheme. If the first 3 
bits equal "001", the flow label will be used as the random 
identifier of the flow, but if they equal "101", the remaining bits 
will include a hybrid QoS requirement for this packet, subdivided 
into traffic type (stringent or best-effort), bandwidth, buffer, and 
delay requirements. Once again, the dependency prohibition in 
[RFC3697] is broken. This proposal also includes throughput 
monitoring and dynamic capacity allocation. Effectively, this 
proposal uses the flow label both to signal Intserv-like QoS 
requirements and to classify traffic into Diffserv-like virtual 
label-switched paths. Packets with a "random" flow label are mapped 
into a generic (best-effort) virtual path. 


3.3. Use Flow Label Hop-by-Hop to Control Switching 


[Chakravorty08b] and [Chakravorty08a] describe an architectural 
framework called "IPv6 Label Switching Architecture" (6LSA). In 
6LSA, network components identify a flow by looking at the Flow Label 
field in the IPv6 packet header; all packets with the same flow label 
must receive the same treatment and be sent to the same next hop. 
However, 6LSA resembles MPLS by considering that a label only has 
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meaning between 6LSA routers and setting the flow label at each hop. 
If the original source sets a non-zero flow label, there is no 
mechanism to restore it before delivery: a fundamental breach of 
[RFC3697]. The authors of [Chakravorty08b] did at one stage discuss 
using an IPv6 hop-by-hop option to correct this problem, but this has 
not been documented. This is a more serious incompatibility than 
simply breaking the dependency prohibition. 


Unlike traditional routing algorithms, but like MPLS, 6LSA packets 
are classified into a Forwarding Equivalence Class (FEC), and routers 
forward packets on different paths by looking at the FEC. Like 
previous solutions, this solution divides the Flow Label field into 
three parts. The first 3 bits identify the FEC, which will help the 
router or 6LSA nodes to group the IP packets that receive the same 
forwarding treatment and forward them on the same virtual path. The 
following 4 bits describe the application type, and the final 13 bits 
(defined by each node or a group of nodes) specify the hop-specific 
label. From the table below, we can see the FEC has 6 major 
categories, each with up to 16 subcategories. 
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Flow Label Specification (shortened from [Chakravorty08b] ) 


Pee Se ee ferences a a tase eee eee see eS + 
| FEC (First 3 Bits) | Next 4 Bits | Purpose 
4------ 55-55 ------ 5-5 +------------- 4------------------ 5-5 + 
| No FEC (000) | 0000 | 
| Domain Specific (000) | 0001 - 1111 | 
| ~=---=--=-==-=--=------- | | | 
VPN (001) 0001 (IPSec - Tunnel Mode) 
0010 (IPSec - Transport Mode) 
| | 0011 | (Special Encryption) 
| | 0100 | (VRE) | 
| | 0101 | (End Network Specific) | 
| | 0110 - 1111 | (Reserved) | 
| ------------------------ | | | 
TE Subset/ 0001 (DiffServ) 
QoS Enhancement (010) 0010 (RSVP) 
| prii | (Reserved) 
| ------------------------ | | | 
| Encapsulation (011) | 0001 | (IPv6 in IPv6) | 
0010 (IPv4 in IPv6) 
0011 (Other in IPv6) 
| | 0100 | (Enterprise Specific) 
| | 0101 - 1111 | (Reserved) | 
| ------------------------ | | | 
| Enterprise Specific(111) | 0000 - 1111 | (Reserved) | 
phena ene pa SSS $---------- 55-55-55 + 


The authors claim that fast switching using 20-bit labels instead of 
128-bit IPv6 addresses will provide memory and processing savings, as 


well as network management advantages. "It also allows a network 
management entity updating available label tables, across the network 
to reduce man-in-the-middle attacks [sic]" [Chakravorty08b]. 


We note that a similar proposal for QoS-based switching of IPv6 
packets [Roberts05] is designed to use a hop-by-hop option, which has 
not so far been allocated by the IETF. Proposals related to this 
have been discussed by the Telecommunications Industry Association 
and the ITU-T [Adams08]. 


We also note that router lookup efficiency was a major concern at the 
time when Clark first proposed a flow label [Deering93], but with the 
advent of very large scale integrated circuits capable of rapid 
lookup in a routing table, most vendors no longer express such 
concern. 
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3.4. Diffserv Use of IPv6 Flow Label 


[Banerjee02] uses the Flow Label field as a replacement for the IPv6 
Traffic Class field; this proposal suggests the incoming flow label 
can indicate the QoS requirement by matching a Diffserv classifier. 
The authors have used the first three bits to indicate this, and the 
following 16 bits to indicate a Differentiated Services Per-Hop 
Behavior Identification code (Diffserv PHB-ID) [RFC3140]; the last 
bit is reserved for future use. This method too breaks the 
dependency prohibition in [RFC3697]. 


[Beckman07a] blends the flow label as an MPLS-like switching tag with 
Diffserv. Unlike 6LSA, the method attempts to bypass the dependency 
prohibition by using one bit in the Diffserv Code Point [RFC2474] to 
indicate that the flow label is a switching tag. In this way, a 
router can determine whether the flow label conforms to [RFC3697] or 
to [Beckman07a]. In [BeckmanO7b], the same author proposes using the 
flow label as a way of compressing IPv6 headers by hashing the 
addresses into the flow label, again using the Diffserv Code Point to 
mark the packets accordingly. 


3.5. Other Uses 


The Integrated Services QoS architecture [RFC1633] specifies that the 
flow label may be used as a packet filter [RFC2205]. At least one 
implementation supported this [Braden10]. 


We are not aware of any proposals combining the flow label with the 
Next Steps in Signaling (NSIS) [RFC4080] architecture. 


[Donleyll1] proposes a use case whereby certain flows encapsulated in 
a particular type of IPv4-in-IPv6 tunnel would be distinguished at 


the remote end of the tunnel by a specific flow label value. This 
would allow a service provider to deliver a tailored quality of 
service. This usage appears to be completely compatible with 
[RFC3697]. 


There has been some discussion of possible flow label use in both the 
ROLL (Routing Over Low power and Lossy networks) [RPL-07] and MEXT 
(Mobility EXTensions for IPv6) working groups of the IETF. Such uses 
tend to encode specific local meanings or routing-related tags in the 
label, so they appear to infringe the dependency prohibition or the 
immutability of the Flow Label field. The ROLL group has indeed most 
recently opted not to use the Flow Label field for these reasons, 
despite having to add the undesirable overhead of an IPv6 hop-by-hop 
option instead [RPL]. Similarly, MEXT has defined a new mobility 
option to support flow bindings [RFC6089] rather than using the IPv6 
Flow Label field. 
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4. 


Conclusion 


Three aspects of the current standard [RFC3697] have caused problems 
for many designers: 


1. The immutability of labels 


2. "Nodes MUST NOT assume any mathematical or other properties of 
the Flow Label" 


3. "Router performance SHOULD NOT be dependent on the distribution 
of the Flow Label values" 


Taken together, these rules essentially forbid any encoding of the 
semantics of a flow, or of any information about its path, in the 


flow label. This was intentional, in accordance with the stateless 
nature of the Internet architecture and with the end-to-end principle 
[Saltzer84], [RFC3724]. It was also felt that QoS encoding via 


Diffserv was sufficient and that the requirement for high-speed 
switching could be met by MPLS. But this means that the majority of 
the proposals described above breach the standard and the intent of 
the standard. The authors often appear to be using the flow label 
either as an MPLS-like switching handle or as an encoded QoS signal. 


In contrast, a few documents mentioned above do appear to respect the 
rules of RFC 3697. These are [Blake09], [Donleyl1], [Carpenter11], 
[Beckman0O7a], and [BeckmanO7b]. Additionally, [Lin06] would have 
joined this list if it had not assigned three flag bits in the Flow 
Label field. Although predating RFC 3697, the Integrated Services 
usage [RFC2205] also seems to be compatible. 


What would other designers need to do, if they wish to respect 

RFC 3697? There appear to be two choices. One is to simply accept 
the existing rules at face value, as in the proposals just listed. 
This limits the application of the flow label. It can, for example, 
be used as a nonce or as part of the material for a hash used to 
share load among alternate paths. It cannot be the only material for 
such a hash, because of the dependency prohibition. The flow label 
could also be used consistently with RFC 3697, if an application 
designer so chose, as a way to associate all packets belonging to a 
given application session between two hosts, across multiple 
transport sessions. This, however, would presumably exclude using 
the flow label to govern routing decisions in any way, and would have 
widespread implications that have never been explored. 


The other choice, for designers who wish to use the flow label to 
control switching or QoS directly, is to bypass the rules within a 
given domain (a set of cooperating nodes) in a way that nodes outside 
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the domain cannot detect. In this case, any deviation from RFC 3697 
has no possible effect outside the domain in question. 


An example scheme to emulate the immutability of labels is as 
follows. Within the domain, all hosts set the label to zero, the 
routers set and interpret the label in any way they wish, and the 
last-hop router always sets the label back to zero. If a packet 
arrives from outside the domain with a non-zero label, there is a 
method (such as a special Diffserv code point) to mark this packet so 
that its label would be ignored and delivered unchanged. An 
alternative approach would be to define a hop-by-hop option to carry 
the original flow label across the domain, so that it could be 
changed within the domain but restored before forwarding the packet 
beyond the domain. 


If a domain allows mutable labels in such a way, it may safely ignore 
the dependency prohibition, and it may set the bits in the label 
according to locally defined rules. Within the domain, the label 
could be used as desired, and most of the proposed designs discussed 
above could be "rescued". 


However, given the considerable number of designers who have proposed 
solutions incompatible with RFC 3697, the relatively few designs 
using the standard rules, and the failure of designs such as ROLL and 
MEXT to make use of the flow label, it seems reasonable to ask 
whether the RFC 3697 standard has value. 


5. Security Considerations 


The flow label is not protected in any way and can be forged by an 
on-path attacker. Off-path attackers may be able to guess a valid 
flow label unless a pseudo-random value is used. Specific usage 
models for the flow label need to allow for these exposures. For 
further discussion, see [RFC3697]. 
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